Description

Previously, examples for checks were stored in separate files for each provider. For example, the examples for Terraform <name> checks were in the <name>.tf.go file, and the examples for CloudFormation were in <name>.cf.go. With the discontinuation of support for Go checks, there is no longer a need to store examples in Go files as it makes them harder to retrieve. Therefore, the examples for each check have been moved from Go to YAML with a new schema:

cloudformation:
  good:
    - |-
       ...
  bad:
    - |-
       ...
terraform:
  good:
    - |-
       ...
  bad:
    - |-
       ...

Currently, the check metadata includes fields for each provider with the same structure:

#   terraform:
#     good_examples: checks/cloud/aws/s3/enable_bucket_logging.yaml
#     links:
#       - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket
#   cloud_formation:
#     good_examples: checks/cloud/aws/s3/enable_bucket_logging.yaml

I have an idea to convert test data for Dockerfile and Kubernetes into examples for integration testing and display on a website. (draft PR). However, the current approach when adding a new provider requires the following steps:

1. Add support for the new provider to the metadata in the Trivy repository.
2. Add a new provider to the metadata of each check.

This process is awkward and inflexible. To simplify it, I propose to introduce a new examples field, which will contain the path to the file with examples to check, replacing the current fields with providers:

#   examples: checks/cloud/aws/s3/enable_bucket_logging.yaml

Along with this, the structure of the example file can be updated to make it more flexible:

providers:
  cloudformation:
    examples:
      good:
        - code: |-
            ...
      bad:
        - code: |-
            ...
  terraform:
    links:
      - https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket
    examples:
      good:
        - code: |-
            ...

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).